【レポート】テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説 〜(AWS-22) #AWSSummit
今回は、2022年5月25 - 26日の2日間で開催されているAWS Summit Online 2022のセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることに、ご活用ください。また、セッションのアーカイブも公開されますので、詳細はそちらをチェックしてください。
本記事は、「テンプレートによる AWS環境のガバナンス〜 Baseline Environment on AWS 徹底解説 〜(AWS-22)」のレポート記事となります。
セッション概要
概要: AWS 上に多様なシステムを構築するにあたって、 全社共通のセキュリティ設定を行いたい場合があります。 どうやって展開およびチェックするのがよいでしょうか？ このセッションではテンプレートを使ってAWS環境のガバナンスを実現する考え方をご紹介します。その実装例であるオープンソース "Baseline Environment on AWS (BLEA)"について、その設計思想や実装の詳細、さらに AWS Cloud Development Kit (CDK)コードを使うことのメリットについて、開発者が解説します。
スピーカー: AWS 技術統括本部 シニアソリューションアーキテクト 大村 幸敬
セッションレベル: Level 300: 中級者向け
セッションリンク（AWS Summit Online 2022 への登録が必要です）
レポート
Agenda
- クラウド活用に必要なガバナンスの考え方
- テンプレートによるガバナンス
- Baseline Environment on AWS（BLEA）の概要
- BLEAベースライン
- BLEAゲストシステムサンプル
- なぜAWS CDKなのか?
前提
- 想定視聴者
- クラウド環境全体の管理者, 全社共通のセキュリティ、ガバナンスを実現したい管理者, AWS上でセキュアなシステムを構築したいエンジニア
- 想定する基礎知識
- AWSセキュリティサービス群の基礎知識
- AWS CloudFormation, CDKの基礎知識
- 「セキュアでスケーラブルな AWS アカウント統制プラクティス最新動向(AWS-19)」のセッションを視聴
クラウド活用に必要なガバナンスの考え方
AWSはBuilderを支えるプラットフォーム
- Builderは適切なツールを選定し自由に組み合わせ、ビジネス価値を早期に構築できる
クラウドが提供する価値
- システム開発でビジネスにフォーカスできる
- 用途にあったサービスを使うことで迅速にシステム開発ができる
- 高可用性、セキュリティ、スケーラビリティの確保
- サービス利用により開発および運用のコストと時間を節約できる - 資産を持たないので変更にも強い
Builderに必要なものは？
- Gatekeeper vs Guardrail
- Gatekeeper:中央集権型でツールの利用を事前承認
- Guardrail: 分散管理。やってはいけない作業だけは止める
- Guardrailを推奨
中央集権型の管理はクラウドの価値を活かし切ることが困難
- 中央集権型管理のよくある課題
- 共通セキュリティポリシーの変更に時間が掛かる
- アカウントが100,1000となった時に手動作業があるとタスクが溢れ、共通運用チームが対応できなくなる
テンプレートを使ったガバナンスの全体像
- 共通運用チームはアカウントの払い出しと最低限のガードレール設定のみを行う
- 実行可能なセキュリティガイドとしてのテンプレートの配布
- 各アカウントの管理責任は各チームが追い、テンプレートも各チームの責任で管理する
- セキュリティイベントの即日うちは各チームで対処
- 重要なセキュリティイベントや定期的な尊守
テンプレートによるガバナンスの考え方
テンプレートを使ったガバナンスの全体像
- 共通運用チームは、セキュリティ設定テンプレートを配布
- セキュリティの設定は個々のチームで行う
- 各チームのメンバーはセキュリティの設定を理解し継続的にメンテナンスを行う
- BLEAの設計思想の基にもなっている5つの考え方
Baseline Environment on AWS (BLEA)
- GitHubへのリンク
- AWSのセキュリティベストプラクティスを実装したオープンソースのサンプルテンプレート
- 基本的なセキュリティを設定するテンプレートとゲストシステムのサンプルテンプレートを提供
Baseline Environment on AWS の利用パターン
- マルチアカウント版とシングルアカウント版がある
- ControlTowerを使った場合は、ゲストアカウントに最低限のログの集約機能を設定を行ってくれる
- BLEAは、これにさらに追加の設定を行う
Baseline Environment on AWS の利用方法
- GitHubからforkし、自社用にカスタマイズ。それを各システムに配布
- ゲストシステムの構成は多様なため、一定ユースケースを考慮したサンプルを提供している
BLEAベースライン
何をベースライン（基本的な設定）とするか？
- BLEAの場合は、アラートが来たら即時調査対応が必要なセキュリティイベントを通知する。という設計にした
BLEAベースラインのセキュリティアラート通知
以下を逸脱した場合に通知される
- SecurityHub
- CIS benchmark, AWS Foundational Security Best Practices の Critical/High
- GuardDuty
- AWSが推奨する Severity を通知
- AWS Config Rules
- NON_COMPLIANT
- AWS Health
- アカウント固有情報
- 発見的ガードレールをどこから始めるかポリシーが決まっていない場合は、まずはBLEAに沿った上で調整していくことを推奨
BLEA ゲストシステムサンプル
- なぜBLEAはゲストシステムサンプルを含むのか？
- AWSのセキュリティサービスを有効化した場合に、通知はされるが、別途セキュリティを確保するための設定が必要だから
- よく使われるユースケースや機能を限定し、その用途に対してSecurity HubのチェックをクリアできるレベルのサンプルCDKコードを提供
- https://github.com/aws-samples/baseline-environment-on-aws/tree/main/usecases
- BLEAゲストシステム例: Webアプリケーション（ECS+HTTP）
- Baseline Environment on AWS - スタック依存関係
- ※動画内資料の構成図をご参照ください
- ガバナンスベースとゲストシステムのサンプルには依存関係はない
- ※（これは個人意見）恐らくサンプルのbin/libを参考にすると良いと思われる
- テンプレートを利用した開発の例
- 多くの場合、ガバナンスベースを大きく変更することはないと思われる
- CDKコードから設定を理解しデプロイする
- 個別のシステムのログやネットワーク構成は、大きく変わらないと思われる（一部パラメータを変更する）
- アプリケーション依存の設計部分は、テンプレートをある程度変えていく必要がある
- 既存の流用できるところをそのまま利用することで、開発スピードを上げることができる
- なぜCDKなのか？
- 初期構築や設定が信頼性高く、一貫した手順で実現できるため
- DevOpsや迅速なソフトウェアデリバリの基盤となる
- コードによってベストプラクティスを共有して同じ設定、同じ手順で展開できる
- 一般的なプログラミング言語（TypeScript）であるためオブジェクト参照が明快
まとめ
- クラウド活用に必要なガバナンスの考え方
- -> 集中型管理はクラウドの価値を活かし切るのが難しい
- テンプレートによるガバナンス
- -> テンプレートを使った分散管理の実現
- Baseline Environment on AWS（BLEA）の概要
- BLEAベースライン
- BLEA ゲストシステムサンプル
- なぜAWS CDKなのか？
最後に
AWS環境のガバナンスを実現するための考え方だけでなく、Baseline Environment on AWSの設計やコードレベルのお話が聞けたことは、かなり貴重だと感じました。また、「なぜCDKを使うのか？」の章では、多くの利点が記載されており、普段TypeScriptで開発している私としては、どれも首を縦に振る内容ばかりでした。
GitHubのHowToもかなり手厚く書かれており、入門者であってもスムーズに導入できるように感じました。
ぜひAWS Summit Onlineに登録して、セッションのアーカイブも確認してみてください！スライド資料も配布されていたので要チェックです。
![[レポート] JJUG CCC 2024 Fallに行ってきました](https://devio2024-media.developers.io/image/upload/v1730277254/user-gen-eyecatch/awivhjatkofztrkayhdv.png)
